数据持久化
变量及其数据的生命周期从创建变量时开始，到删除变量和释放内存时结束。创建、初始化或实例化变量的时间取决于声明的范围。释放内存的时间通常也取决于范围。例如，全局变量的内存通过退出应用程序来释放。
他们可以比平时更长时间地保留数据。中的以下机制 CODESYS 为此目的而提供。
数据保存机制
比较机制
哪种机制适用于哪种应用？该表考虑了一些常见的用例。具体示例是指房屋控制。
用例 | (A) 持久变量 | (B) 保留变量 | (c) 持久性管理器变量 | (D) 配方变量 | |
|---|---|---|---|---|---|
1 | 应用程序必须接收设备设置。 示例：电源故障后，房屋控制必须提供有关百叶窗需要升起多长时间的信息。 | 合适的1 首选用例 在这种情况下，您还可以使用保留变量而不是持久变量。这对于声明经常更改的变量是有利的。 | 合适的 首选用例 当变量的声明经常更改时，保留变量是有利的。 | 合适的2 有利于没有任何硬件支持的控制器 这是通过特殊功能（例如双文件缓冲）实现的。 | 可能，但非常麻烦，因此不推荐 |
2 | 应用程序还必须在程序更改或扩展后接收值。 | ||||
2a：稀有扩展 示例：应用程序员在程序中添加了一个新开关并安装了一个新灯。房屋控制必须仍然具有到目前为止已保存的值。 | 合适的1 首选用例 | 合适的 | 合适的2 | 可以，但很麻烦 | |
2b：更自由的更改，包括删除或更改变量的数据类型 房屋控制正在运行并持续存在。如果应用程序程序员使用新功能扩展控件并因此在功能块中使用进一步的持久变量，则必须保留到该点保存的值。例如，程序在 FB 中通过一个变量扩展，该变量控制在特定时间后自动关闭先前不受控制的灯。扩容后，房控必须有所有受控灯的时间可用。 | 不合适 | 合适的 在线更改后，保留变量中的数据将尽可能保留。 | 合适的， 越远越好 2 首选用例 | 如果有文字可能，但很尴尬 | |
2c：应用程序必须在下载后接收值。 | 合适的 | 不合适 | 合适的 | 合适的 | |
3 | 应用程序必须能够使用不同的值集。 示例：夏季、冬季和假期的运行设置必须根据需要保存并重新导入。 | 不合适 | 不合适 | 不合适 | 合适的 首选用例 |
4 | 应用程序必须能够使用其他系统的设置。 必须可以将设置传输到使用类似变量的另一个系统。 | 不合适 | 不合适 | 合适的2 | 合适的3 |
5 | 应用程序必须提供人类可读的数据。 用户必须能够读取、比较和编辑数据。 | 不合适 | 不合适 | 合适的2 | 合适的3 |
1 缺点：只有在运行时系统支持此机制并且 NVRam 内存或 UPS 可用时才有可能。优势：速度；推荐用例：1 和 2a
2 缺点：在大量变量（> 10000）的情况下，初始化和关闭需要很长的等待时间。优点：不需要特殊的内存设备；价值保留也适用于更改、扩展或删除。
3 优点：外部可编辑，可转移。缺点：尴尬
调用在线命令时变量的生命周期
菜单中的用户输入 在线的 | 具有通常寿命的变量 两者都不 |
|
|
|---|---|---|---|
命令 在线更改 | x | x | x |
命令 重新设置温暖 | i | x | x |
命令 冷复位 | i | i | x |
命令 加载 | i | i | X 1 |
命令 重置原点 | i | i | i |
x ：变量保持其值。
i : 变量被初始化。
1 注意：关于持久化数据的结构，请注意“下载机制”下的信息。
加载引导应用程序时变量的寿命
正常变量的值会丢失其值并重新初始化。
持久变量的值受到保护
当内存中持久变量的结构与持久数据列表中的结构匹配时。
当持久数据仅被扩展时。在这种情况下，只有最近添加的变量被设置为默认值。
保留变量的值受到保护
当内存中保留变量的结构与持久数据列表中的结构匹配时。
当保留变量与应用程序匹配时（GUID 必须匹配）。
如果在应用启动时不满足retain variables和persistent variables的值恢复要求，就会出现“retain mismatch”。硬件制造商的文档中描述了对这种差异的反应。
有关详细信息，请参阅： 使用持久变量保存数据